Hi,

in case after you flashed the firmware it doesn't work automatically, you must delete the device associated key in usbflags from the windows registry. Windows stores all the usb devices that answer or not the os string descriptor call. If the device doesn't answer the os string descriptor call, windows store that information in the registry and doesn't call again for that device "triplet" so it won't load the winusb driver. If the device answers, then it stores that it needs to call during enumeration, for feature descriptor associated with the MS_VENDOR_CODE.

The registry key is :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags<VVVVPPPPRRRR>
Where
vvvv is the vendor id
pppp is the product id
rrrr is the revision number of the device.

meaning that for usbasp 1.07 is :

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\16C005DC0107

Why is the OS String descriptor array 18 bytes long, but bLength is 20 (0x14)?
I think the code would be cleaner using a UTF-16 string initialization. i.e. u“MSFT100”.

Hi,

Why is the OS String descriptor array 18 bytes long, but bLength is 20 (0x14)?

Because this is what the caller requires.

"Version 1.00 of the OS string descriptor has a fixed length of 18 bytes, with a structure as shown in the following table. This format MUST be used by all OS string descriptors.

Length: An unsigned byte and MUST be set to 0x14.

Type: An unsigned byte and MUST be set to 0x03.

Signature: A Unicode string and MUST be set to "MSFT100".

MS Vendor Code: An unsigned byte, it will be used to retrieve associated feature descriptors.

Pad: An unsigned byte and MUST be set to 0x00."

See "3.3.5.3.9 Processing an OS Descriptor request" https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpeusb/c2f351f9-84d2-4a1b-9fe3-a6ca195f84d0.

I think the code would be cleaner using a UTF-16 string initialization. i.e. u“MSFT100”.

Maybe you're right. I personally prefer it as an array in progmem because it's a simple array as stated in the "3.3.5.3.9 Processing an OS Descriptor request" document :

"•The Signature field contains a Unicode character array that identifies the descriptor as an OS string descriptor and includes the version number. For version 1.00, this array must be set to "MSFT100" (0x4D00 0x5300 0x4600 0x5400 0x3100 0x3000 0x3000)."

Hi,

I added some comments explaining in general the mechanism.

EDIT: As I re-read the "Microsoft OS Descriptors for USB Devices" I missed that this process is supported and in Windows 7, so you can test it on your windows box.

Hi,

I can't test it anyway, so I probably won't merge it.

IMHO, you can test it on your windows 7 box but it's your call.

Hi,

I can't test it anyway, so I probably won't merge it.

IMHO, you can test it on your windows 7 box but it's your call.

The MS docs are inconsistent and even contradictory in places. I guess I'll give it a try and see. I'll bump the release number (bcdDevice) to ensure the cached libusb driver association isn't used.

@dioannidis, is there a reason why this is in RAM, and not flash?
https://github.com/dioannidis/usbasp/blob/master/firmware/main.c#L160

I was going to open an issue in your fork, but you don't seem to have it enabled.

I cloned your fork, turned on -Wextra, and found some warnings that I think should be cleaned up:

main.c:162:2: warning: missing initializer for field 'reserved' of 'usbExtCompatHeader_t' {aka 'struct <anonymous>'} [-Wmissing-field-initializers]
  { sizeof(usbExtCompatDescriptor_t), 0x0100, 0x0004, 1 },
  ^
main.c:147:10: note: 'reserved' declared here
  uint8_t reserved[7];
          ^~~~~~~~
main.c:167:1: warning: missing initializer for field 'reserved2' of 'usbExtCompatDescriptor_t' {aka 'const struct <anonymous>'} [-Wmissing-field-initializers]
 };
 ^
main.c:157:10: note: 'reserved2' declared here
  uint8_t reserved2[6];
          ^~~~~~~~~

Hi,

@dioannidis, is there a reason why this is in RAM, and not flash?
https://github.com/dioannidis/usbasp/blob/master/firmware/main.c#L160

For no specific reason except that I used Marius code . If you look at the code above typedef's you'll see a comment : "/* TODO: Change them to progmem consts */"

Hi,

< snip >

The MS docs are inconsistent and even contradictory in places. I guess I'll give it a try and see. I'll bump the release number (bcdDevice) to ensure the cached libusb driver association isn't used.

As I don't have a box or vm with windows 7 ( and didn't had the time to setup one ) I'm curious to see if it works as Microsoft claims .

Hi,

@dioannidis, is there a reason why this is in RAM, and not flash?
https://github.com/dioannidis/usbasp/blob/master/firmware/main.c#L160

< snip >

For no specific reason except that I used Marius code . If you look at the code above typedef's you'll see a comment : "/* TODO: Change them to progmem consts */"

Moved to flash. Tested in Windows 10 64bit.

I don't think there is anything more to do. @nerdralph, If there is something I missed, I'll be happy to fix it.

regards,

I just finished testing, and I think it works. I'm not sure how to remove the .inf that associates 0x16C0/0x05DC with libusb, so I'm still seeing it associate with libusb even after I deleted the usbflags regkey. My reason for suspecting it is working is because Zadig shows it as having WCID.

p.s. I started writing the comment before your latest. Having all descriptors in flash is something I wanted because it gets the binary below 4096 bytes, which means it can work with a mega48.